1. Field of Invention
The present invention relates generally to document image processing, and more particularly to systems and methods for processing image documents using a common exchange format.
2. Description of Related Art
Office multi-function devices have traditionally not shared a large proportion of image processing resources. This lack of resource sharing may lead to higher unit costs and significant visual differences between hard copy output that is printed and hard copy output that is copied. Additionally, devices have not had the ability to create local copies and remote copies with the same image quality and copy speed because the representations used to perform these functions are vastly different. Further, the same resources are not used to perform both the copy function and the scan function.
Printing color documents involves a series of data conversions. FIG. 1 is a schematic diagram illustrating a process 100 that includes, at a high level, various translations and conversions that are used to convert a document from, for example, a Windows™ application to, for instance, a hard copy. As shown in FIG. 1, the translation between an application and a hard copy involves, for example, converting the client document 110 from its internal structure or format to Graphic Device Interface (GDI) calls, then the GDI is translated to PostScript, PCL, or some other standard Page Description Language (PDL) in a conversion module 120. The PDL is next transmitted over a network, such as a local area network, to a printing device 130 which converts the vector representation of the document to a raster representation of the document.
Generally, for non-impact printers, the image to be printed is represented in a raster form (i.e. a rectangular array of “pixels”) that represent image colors. For color printing, there are typically several of these raster images per page, each representing a “primary” separation of the image. Typical color separations for printing are cyan, magenta, yellow, and black. A raster image processor, or RIP, converts the page description language representation of the page into the raster image representation of the page. The raster image, once “RIP”ed, is stored in a frame buffer. When it is time to convert the image to hard copy output form, the image in the frame buffer is processed and converted to video signals to drive the image output terminal (IOT) at a speed that will keep up with the process speed of the output device. The conversion from frame buffer raster to the video signal may include filtering, scaling, halftoning, or other image processing functions. The important characteristic is that the frame buffer representation must be in a format that can be converted at engine speed to video signals that can drive a marking device (such as a laser or LED bar). Frame buffers contain raster images that are either binary, low bits per pixels (bpp) coded contone (halftoned), or full contone (at least about 8 bits per pixel, where the magnitude of the digital value represents the amount of colorant to put on the page). For binary or coded contone frame buffers, halftone quality is closely coupled to frame buffer raster resolution: The higher the resolution, in general, the higher the quality. In contrast, contone frame buffer resolution can be independent of raster resolution. There generally is a trade off between RIP speed and raster resolution. Color conversion is generally performed in the RIP software unless there is specialized acceleration hardware.
There are several drawbacks to the current approach for processing image documents. For instance, in the current approach, printing is a monolithic process. Thus, it is difficult to move parts of the processing to different points in the compute process chain. For instance, the existing approaches, including the model shown in FIG. 1, will not support conversion of the vector representation to a high level compact raster representation using a resource that existed on the Internet. Also, color correction is performed in the RIP, which takes considerable time and, accordingly, reduces productivity of the device. Moreover, for binary and low bpp contone, halftoning is performed in the RIP, which also takes time and reduces productivity. Performing halftoning in the RIP can incur significant performance penalty, especially if the halftones are large such as in typical color devices. Additionally, some compression algorithms are tuned to halftone details, which translate into an additional time penalty to optimize the compression when the halftone changes. Furthermore, document images that are halftoned during the RIP process are not very compressible because they must use lossless image compression algorithms. This problem is made significantly worse when the halftoning method is ‘noisy’ (e.g. using stochastic screens or error diffusion).